Amazon Connect 公式ブートキャンプをやってみよう！ – STEP 1「メニューを備えた基本的な問い合わせフロー」

「ステップ・バイ・ステップ」でAmazon Connectを使ったコールセンターシステムの構築方法を解説します。(連載記事全6回の第2回目)

#Amazon Connect

#コールセンター

#AWS

青柳英明

2021.10.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさん、こんにちは！
福岡オフィスの青柳です。

AWSから公開されている「Amazon Connect Bootcamp」を題材に「ステップ・バイ・ステップ」で構築方法を解説する連載記事の第2回目です。

STEP 0：「準備編」
STEP 1：「メニューを備えた基本的な問い合わせフロー」 ← 当記事です
STEP 2：「発信者番号による顧客情報の照会と本人確認」
STEP 3：「新規問い合わせ時のコールバックの実装」
STEP 4：「既存問い合わせ対応の実装」
STEP 5：「メニューをDTMFからAmazon Lexへ変更」

前回の「STEP 0：準備編」にて、コールセンターのシステムを構築するために必要な準備を行いました。
今回はいよいよ本編の構築に入って行きます。

今回の構築範囲

今回は、図で「黄色」で表示されているフロー、すなわち

Flow 1：「全般的なパラメーターの設定」
Flow 2：「営業時間のチェック」
Flow 5：「メニューの選択」

を構築します。

ただし、黄色以外の「灰色」で表示されているフローについても「枠」だけ作成しておきます。枠だけですので、中身はほぼ「空っぽ」の状態です。

最初に全てのフローを作成しておくことで、以後のステップでの構築を行い易くする狙いです。一度に8個ものフローを作成しなければならないので少し大変かもしれませんが、頑張って行きましょう！

フローの構築

Flow 1「全般的なパラメーターの設定」

前回の「STEP 0：準備編」で動作テスト用に「BootCampFlow1」を作成しましたが、今回は前回作成したフローの枠を流用します。一度、配置されているブロックを全て削除して、最初の「エントリポイント」のみにしましょう。

新たに作成するフローの全体図はこのようになります。

(1)～(6)の各ブロックは、いずれもAmazon Connectの動作に関する設定を行うものです。

各ブロックの設定内容を説明します。

(1) 「設定」-「ログ記録動作の設定」

フローの動作ログを記録するかどうかを設定します。

ログ記録の動作：「有効化」を選択

ログ記録を有効にすると、CloudWatch Logsのロググループ/aws/connect/＜Amazon Connectインスタンス名＞にログが記録されるようになります。

(2) 「設定」-「音声の設定」

機械音声による読み上げで使われる言語と性別を選択します。

言語：「日本語」を選択
音声：「Mizuki」を選択
言語属性を設定：チェックを入れる

日本語の場合、女性の「Mizuki」と男性の「Takumi」が選択可能です。

(3) 「設定」-「記録と分析の動作を設定」

通話で会話された顧客とエージェントの音声 (どちらか一方または両方) を記録するかどうかを設定します。

通話記録：「オン」→「エージェントおよび顧客」の順に選択

記録された音声データはS3バケットamazon-connect-XXXXXXXXXXXX/connect/＜Amazon Connectインスタンス名＞/CallRecordingsに格納されます。 (インスタンスの設定で変更可能)

(4) 「設定」-「保留フローの設定」

「保留フロー」と呼ばれる特殊なフローに関する設定です。

保留フロー：「エージェント」→「フローの選択」の順に選択
フロー：「Default agent hold」を選択

Amazon Connectの「フロー」には、今作成している「BootCampFlow1」のような「問い合わせフロー (コンタクトフロー)」の他に、特定の場面で使われるいくつかのフローの種類があります。今回はフローの種類や内容については説明を割愛しますが、特定の場面での動作をカスタマイズしたい場合には、該当する「フロー」を作成した上で、「〇〇フローの設定」ブロックで「どの場面でどのフローを使うのか」を設定する必要があります。

「〇〇フローの設定」ブロックは必須ではなく、フローを設定しなかった場合にはデフォルトのフローが使われます。

今回、(4)、(5)、(6)でフローの設定を行っていますが、実は全てデフォルトのフローが選択されています。つまり、ブロックを配置していますが、配置しない場合と全く同じです。フローを設定する場合は「〇〇フローの設定」ブロックを配置して設定を行うということだけ覚えておいてください。

(5) 「設定」-「顧客キューフローの設定」

顧客キューフロー：「フローの選択」を選択
フロー：「Default customer queue」を選択

(6) 「設定」-「ウィスパーフローの設定」

ウィスパーフロー：「送信先: エージェント」→「フローの選択」の順に選択
フロー：「Default agent whisper」を選択

(7) 「終了/転送」-「フローへの転送」

ここまでのブロックで一連の設定が終わりましたので、次のフロー「Flow 2：営業時間のチェック」へ制御を移します。

転送：「フローの選択」を選択
フロー：「BootCampFlow2」を選択

ここで「BootCampFlow2」が選択肢に現れないことに気付いたと思います。

そうです、まだBootCampFlow2以降のフローは何も作成していませんので、選択できないのは当然です。

ここでは、暫定的に適当なフロー (例えば「Sample AB test」など) を選択しておきます。全てのフローを作成した後に、本来のフローに設定を変更することにします。

(8) 「終了/転送」-「切断」

設定項目はありません。

フローの全体図を見ると、4つのブロックの「エラー」から、この「切断」ブロックに線が繋がっているのが分かります。これは、各ブロックで何らかの原因 (設定ミス、Amazon Connectの内部エラー) でエラーが発生した場合に通話を強制切断するという意味です。

今回はサンプルのため強制切断でも問題ありませんが、実際の運用環境ではエラー発生時に何らかの対処を行った方が良い場合もあるでしょう。 (例えば「申し訳ございません、問題が発生したため通話を終了します」アナウンスを流すなど)
その場合は、「プロンプト再生」などのブロックを追加して、「エラー」から線を繋ぐことになります。

ちなみに、エラー発生時に何も対処しないからと言って「エラー」からどこにも線を繋がないと、フローの「公開」時にエラーとなります。必ず何らかのブロックへ線を繋ぐようにしましょう。

これで「Flow 1」の設定は終わりです。 (「フローへの転送」ブロックのみ、後ほど設定を変更します)

Flow 2「営業時間のチェック」

ここからは、フローを新規に作成していきます。

フローの全体図はこのようになります。

連載第1回の「STEP 0：準備編」で「オペレーション時間」の作成を行い、営業時間を「月曜日から金曜日」「午前9時～午後5時」と設定したことを覚えていますでしょうか？

ここでは、この「オペレーション時間」の設定を用いて、顧客から電話が掛かってきた際に「営業時間内か営業時間外か」の判定を行います。

(1) 「ブランチ」-「オペレーション時間を確認する」

どの「オペレーション時間」の定義を使って営業時間の判定を行うのかを指定します。

指定時間：「BusinessHours」を選択

このブロックを見ると、出力が「時間内」「時間外」「エラー」の3つに分かれていることが分かります。営業時間の判定の結果、営業時間内であれば「時間内」の先に続くブロック、営業時間外であれば「時間外」の先に続くブロックへ処理が遷移するという訳です。 (「エラー」については、前の「Flow 1」で解説した通りです)

このように、「ブランチ」に所属するブロックは、何らかの判定や条件分岐に従って複数の後続ブロックに処理を分岐する機能を持っています。

(2) 「終了/転送」-「フローへの転送」

営業時間内であれば、次のフロー「Flow 3：顧客情報の照会」へ制御を移します。 (ただし、前述した通り現時点では「BootCampFlow3」が選択できませんので、ダミーのフローを選択状態にしておきます)

転送：「フローの選択」を選択
フロー：「BootCampFlow3」を選択 (※現時点ではダミーのフローを選択)

(3) 「操作」-「プロンプトの再生」

営業時間外であった場合は、営業時間外である旨を知らせるアナウンスを流してから、通話を終了します。

プロンプト：「テキスト読み上げまたはチャットテキスト」→「テキストの入力」の順に選択
テキスト：「ただいまの時間は営業時間外となっております。」と入力
解釈する：「テキスト」を選択

「プロンプトの再生」ブロックでは、指定したテキストを機械音声で読み上げてくれます。 (もちろん日本語でOKで、漢字もある程度ちゃんと読んでくれます)

「解釈する」の「テキスト」は、「テキストに入力した文字列をそのまま読み上げてもらう」という意味です。他の選択肢については、今後のステップで出てくるため、その際に解説します。

(4) 「終了/転送」-「切断」

設定項目はありません。

このフローでは「営業時間外の場合の通話終了」と「エラー発生時の強制切断」を一つの「切断」ブロックで兼ねた形となります。

これで「Flow 2」の設定は終わりです。

Flow 3「顧客情報の照会」

フローの全体図はこのようになります。

冒頭で説明した通り、今回の「STEP 1」では、このフローについては「枠」だけで中身はほぼ「空っぽ」です。

(1) 「ブランチ」-「コンタクト属性を確認する」

「コンタクト属性」(単に「属性」とも言う) とは、Amazon Connectのフロー内で利用できる変数のようなものです。この「コンタクト属性を確認する」ブロックでは、指定した「属性」の値を使った条件分岐を行うことができます。

確認する属性：
- タイプ：「システム」を選択する
- 属性：「チャネル」を選択する
チェックする属性：
- 「別の条件の追加」をクリックする
- 「等しい」「VOICE」を選択する

タイプ「システム」に属する「チャネル」という属性の値を判定しています。

属性「チャネル」には、現在のフローの対象となる顧客がAmazon Connectにコンタクトを行った「手段」がセットされていて、取り得る値は「VOICE」「CHAT」「TASK」の3種類があります。今回は電話によるコンタクトのみを対象として処理を行いたいため、属性「チャネル」の値が「VOICE」であるか、それ以外であるかを判定します。

(2) 「終了/転送」-「フローへの転送」

チャネルが「VOICE」である場合のみ、次のフロー「Flow 4：本人確認」へ制御を移します。

転送：「フローの選択」を選択
フロー：「BootCampFlow4」を選択 (※現時点ではダミーのフローを選択)

(3) 「終了/転送」-「切断」

設定項目はありません。

以上のように、このフローでは「チャネル」の判定のみ行っているということになります。正直なところ、何故このフローで「チャネル」の判定処理を行っているのかはよく分かりません。 (もっと最初の方の「Flow 1」とかで処理しても良さそうなんですが)

これで「Flow 3」の設定は終わりです。

Flow 4「本人確認」

フローの全体図はこのようになります。

本人確認の処理はまだ実装せず、このステップでは顧客への最初のアナウンス「お電話ありがとうございます」を流すのみです。

(1) 「操作」-「プロンプトの再生」

プロンプト：「テキスト読み上げまたはチャットテキスト」→「テキストの入力」の順に選択
テキスト：「お電話ありがとうございます。」と入力
解釈する：「テキスト」を選択

(2) 「終了/転送」-「フローへの転送」

次のフロー「Flow 5：メニューの選択」へ制御を移します。

転送：「フローの選択」を選択
フロー：「BootCampFlow5」を選択 (※現時点ではダミーのフローを選択)

(3) 「終了/転送」-「切断」

設定項目はありません。

これで「Flow 4」の設定は終わりです。

Flow 5「メニューの選択」

フローの全体図はこのようになります。

このフローが「STEP 1」のメインとなります。

(1)で顧客にキー操作によってメニューを選択してもらい、その結果で3つのルートに分岐します。また、メニューの操作で意図しない入力をされた場合や操作間違いがあった場合、3回まで再入力を受け付ける「リトライ処理」を組み込みます。

まず、顧客のキー操作を判定するブロックです。

(1) 「操作」-「顧客の入力を取得する」

設定項目が多いため、前半と後半に分けます。

まず、顧客に入力を促すためのアナウンスを設定します。

プロンプト：「テキスト読み上げまたはチャットテキスト」→「テキストの入力」の順に選択
テキスト：「購入前のご相談は1を、新規のお問い合わせは2を、以前のお問い合わせについては3を、押してください。」と入力
解釈する：「テキスト」を選択する

キー操作の受け付ける範囲を設定します。「DTMF」(Dual-Tone Multi-Frequency) とは電話のプッシュボタン入力を電話回線で伝送する方式の名前であり、ここでは「顧客の入力方法はプッシュボタンとする」ことを指定しています。

入力方法：「DTMF」タブを選択
タイムアウトの設定：「5秒」と入力 (適宜調整してください)
オプション：「別の条件を追加」をクリックして、以下の値を入力 (3回繰り返す)
- 「1」
- 「2」
- 「3」

アナウンス内容の通り「1」「2」「3」の3通りの入力を受け付ける必要があるため、オプションに各番号を設定します。

～～～

続いて、「1」「2」「3」が押された時の「正常系」の処理を説明・・・したいところですが、その前に、正規の入力がされなかった時の「異常系」の処理を説明します。

「顧客の入力を取得する」ブロックで「タイムアウト」(時間内にキーが押されなかった)、「デフォルト」(指定された番号以外が入力された)、「エラー」(エラーが発生した) のいずれかが発生した場合に、このルートに入ります。

(2) 「操作」-「プロンプトの再生」

プロンプト：「テキスト読み上げまたはチャットテキスト」→「テキストの入力」の順に選択
テキスト：「入力された番号が確認できませんでした。」と入力
解釈する：「テキスト」を選択

(3) 「ブランチ」-「ループ」

ループ：「ループの数」を選択
ループ数：「3」を入力

「ループ」ブロックは、このブロックを通過した回数を記憶して、指定された回数までは「ループ」へ出力、指定された回数を超えた場合は「完了」へ出力、と遷移先を分岐します。

「ループ」の先には (1)「顧客の入力を取得する」があるため、再度顧客へ入力を求めます。

「完了」の先には後に説明する (6)「作業キューの設定 (InquiryQueue)」があります。つまり、一定数リトライしても正規の入力が確認できなかった顧客は「新規問い合わせ (Inquiry)」のオペレーターが対応するということです。

～～～

続いて、「1」「2」「3」が押された時の「正常系」処理を説明します。

「顧客の入力を取得する」ブロックで「1」「2」「3」のいずれかが入力された場合、それぞれ「急ぎ 1」「急ぎ 2」「急ぎ 3」が出力先として対応しています。

※ コンソール表示を日本語にしていると「急ぎ 1」と表記されており意味不明なのですが、これは「Pressed 1」(＝1が押された) の誤訳であるようです。(確かに「(be) pressed」には「逼迫した」などの意味もありますが・・・)

まず、「1」が押された、すなわち顧客が「購入前のご相談」を選択した場合です。

(4) 「設定」-「作業キューの設定」

現在の顧客からの電話をどのキューに入れるか、という設定です。キュー設定には「一度設定すると上書きされるまで設定が有効になる」「設定はフローを跨いで有効」という特徴があります。

出力：「キュー別」→「キューの選択」の順に選択
キュー：「SalesQueue」を選択

「1」(購入前のご相談) が押されたため、対応するキュー「SalesQueue」を指定します。

(5) 「終了/転送」-「キューへ転送」

顧客からの電話を、現在設定されているキューに入れます。これによって、エージェントが対応可能になり次第、顧客の電話はエージェントへ繋がります。

「キューへ転送」タブを選択

設定はこれだけです。
「キューへ転送」ブロックで転送先のキューを指定することはできないため、必ず、このブロックに到達する前に「作業キューの設定」ブロックでキューを指定するようにフローを組み立ててください。

次に、「2」が押された、すなわち顧客が「新規のお問い合わせ」を選択した場合です。

(6) 「設定」-「作業キューの設定」

出力：「キュー別」→「キューの選択」の順に選択
キュー：「InquiryQueue」を選択

「2」(新規のお問い合わせ) が押されたため、対応するキュー「InquiryQueue」を指定します。

(7) 「終了/転送」-「フローへの転送」

新規問い合わせの場合は、エージェントへ繋ぐ前にまだ処理が必要なため、次のフロー「Flow 6：新規問い合わせ」へ制御を移します。

転送：「フローの選択」を選択
フロー：「BootCampFlow6」を選択 (※現時点ではダミーのフローを選択)

次に、「3」が押された、すなわち顧客が「既存のお問い合わせ」を選択した場合です。

(8) 「設定」-「作業キューの設定」

出力：「キュー別」→「キューの選択」の順に選択
キュー：「SupportQueue」を選択

「3」(既存のお問い合わせ) が押されたため、対応するキュー「SupportQueue」を指定します。

(9) 「終了/転送」-「フローへの転送」

既存問い合わせの場合も、次の処理を行うために、フロー「Flow 7：既存問い合わせ」へ制御を移します。

転送：「フローの選択」を選択
フロー：「BootCampFlow7」を選択 (※現時点ではダミーのフローを選択)

最後に、このフローの終端となる「切断」ブロック(10)(11)を配置します。

これまでのフローでは「切断」ブロックはフロー内に1つだけ存在していました。

しかし、このフローのように複雑なフローの場合には、無理に「エラー」から「切断」へ線を繋ぐと、各々の線が交錯して見辛くなってしまいます。そのような場合には、複数の「切断」を配置して、上手く配線をコントロールすると良いでしょう。

これで「Flow 5」の設定は終わりです。配置するブロックが多いので疲れましたね。残りは単純なフローのみですので、あと少し頑張って続けましょう。

Flow 6「新規問い合わせ」

フローの全体図はこのようになります。

今後、このフローに新規問い合わせ時の処理を実装していきますが、現時点では「キューへ転送」のみです。

(1) 「終了/転送」-「キューへ転送」

「キューへ転送」タブを選択

このブロックに到達するまでに、1つ前のフロー「Flow 5」でキューを「InquiryQueue」に設定しています。したがって、顧客の電話は「InquiryQueue」キューに入り、サポート部門オペレーターへ繋がります。

Flow 7「既存問い合わせ」

フローの全体図はこのようになります。

今後、このフローに既存問い合わせ時の処理を実装していきますが、現時点では「フローへの転送」のみです。 (既存問い合わせの処理は「Flow 7」「Flow 8」の2つのフローを使って実装します)

(1) 「終了/転送」-「フローへの転送」

転送：「フローの選択」を選択
フロー：「BootCampFlow8」を選択 (※現時点ではダミーのフローを選択)

Flow 8「前回対応したオペレーターへ繋ぐ」

フローの全体図はこのようになります。

今後、このフローに既存問い合わせ時の後半の処理を実装していきますが、現時点では「キューへ転送」のみです。

(1) 「終了/転送」-「キューへ転送」

「キューへ転送」タブを選択

このブロックに到達するまでに、2つ前のフロー「Flow 5」でキューを「SupportQueue」に設定しています。したがって、顧客の電話は「SupportQueue」キューに入り、サポート部門オペレーターへ繋がります。

フローの接続を修正する

最後の仕上げとして、ここまで各フローにおいて「暫定的」に設定していた「フローへの転送」ブロックについて、本来の転送先フローへ設定を修正します。

まず、「Flow 1」から「Flow 8」までの各フローで「公開」をクリックして、フローが公開済みの状態にします。フローが公開されていなければ、転送先フローの選択肢に現れないからです。

フローを公開しましたら、各フローの「フローへの転送」ブロックの設定を以下のように修正します。

「Flow 1」
- (7) の「フローへの転送」ブロック：転送先フローを「BootCampFlow2」に設定する
「Flow 2」
- (2) の「フローへの転送」ブロック：転送先フローを「BootCampFlow3」に設定する
「Flow 3」
- (2) の「フローへの転送」ブロック：転送先フローを「BootCampFlow4」に設定する
「Flow 4」
- (2) の「フローへの転送」ブロック：転送先フローを「BootCampFlow5」に設定する
「Flow 5」
- (7) の「フローへの転送」ブロック：転送先フローを「BootCampFlow6」に設定する
- (9) の「フローへの転送」ブロック：転送先フローを「BootCampFlow7」に設定する
「Flow 7」
- (1) の「フローへの転送」ブロック：転送先フローを「BootCampFlow8」に設定する

修正後、再度フローを「公開」するのを忘れないでください。

動作テスト

さて、これで「STEP 1：メニューを備えた基本的な問い合わせフロー」の全ての設定が終わりました。

前回と同様に、実際に電話を掛けてみて動作を確認しましょう。

準備：エージェントのログイン・CCP起動

準備として、エージェントがコンソールにログインして、CCPを起動することで、電話を待ち受けられる状態にしておきます。手順は前回の記事を参照してください。

今回のステップからは、エージェントが「セールス部門エージェント」と「サポート部門エージェント」の2種類いることに注意してください。それぞれの部門から1人ずつ「ichiro」「saburo」の2人のエージェントでログインした状態にしておくのがベストですが、ブラウザのシークレットウィンドウを駆使しても同時に1人のエージェントしかログインできないかもしれないですね。

その場合は、テストのシチュエーションに応じて適切なエージェントでログインした状態にしておきます。今回のテストでは、まずは「セールス部門」担当のエージェント「ichiro」でログインしておきましょうか。